Add a Web Services trading partner delivery. For details, see Add a Web Services trading delivery.
Enable this delivery
Select or deselect this option to enable or disable the transport.
Name
Name of the delivery.
Make this the default delivery
When you have multiple deliveries, one of the deliveries must be designated as the default delivery.
URL
The partner's web service URL.
This server requires a user name and password
Select this option if the partner's server requires a user name and password. Then complete the fields: User name, Password, Confirm password.
Use a proxy to access this server
Select this option if you must pass through a proxy to reach the delivery server. For partner exchanges, the proxy is located between Activator and the partner HTTP server.
Host
The URL of the proxy host.
Port
The port where the proxy host listens for connections.
This proxy requires a user name and password
Select this option if the proxy server requires a user name and password. Then complete the fields: User name, Password, Confirm password.
By default, exchange points are active continuously. You can add active schedules by day of the week and time of day. For example, if you select Monday 0:00 - 23:59, the exchange is on all day every Monday. If you select Monday 8:30 - 11:30, the exchange is on from 8:30 to 11:30 a.m. and off all other times on Mondays.
Maximum concurrent connections
The number of total open connections
Retries
The number of times Activator will retry connecting to the partner’s transport if the initial attempt to connect and send the message failed.
Connect timeout
Time in seconds Activator waits for a connection to the delivery before the attempt times out. Although the default value is 30 seconds, this may be longer than the interval allowed by your operating system (OS). For example, Windows XP by default allows a maximum timeout of 20 seconds. The actual connect timeout interval is the lesser of the OS timeout and the value set in Activator.
Read timeout
The maximum number of seconds the server waits when reading data from a partner.
Response timeout
The interval in seconds partners are allotted to return search results requested by your local server.
Enable HTTP chunking
Select this option if you are sending files larger than 2 gigabytes. You may also enable chunking for small messages. However, if your partners use a trading engine other than
Attempt restarts
Select this option to turn on checkpoint-restarts. A checkpoint is information saved to disk that is used as a recovery point in the event of a transport failure. The restart program uses the last saved checkpoint and starts again, ensuring no loss of data.
Checkpoint files are saved on the server under the <install directory>/common/data/http/restartable.
To reduce unnecessary overhead when processing small files, checkpoint files are only created for messages that are at least 100 KB in size.
If a restart is attempted for a message whose checkpoint file on the server is more than four hours old, the checkpoint file is discarded and the entire message is retransmitted.
The restart logic is used only during transport retries, such as might occur when a transfer is interrupted due to network problems. If you resubmit a message in Message Tracker, no attempt is made to perform a checkpoint-restart.
This feature only works if your partner uses Interchange or Activator and its embedded HTTP server. Do not select this option if a partner uses an external or staged HTTP server or uses a trading engine other than Interchange or Activator.
Enable use of 102-processing
Select this option to ensure that the connection between the client and server does not become idle and fail while message processing is in progress. For example, this makes sure the connection remains active when the client is sending a multi-gigabyte message. Or, to prevent a firewall from disconnecting an idle connection before the server receives the entire message and returns a 200 OK response. Most often this setting is useful when the client requests a synchronous receipt, but also could be recommended in some cases for an asynchronous receipt.
Selecting this option directs Activator to add the following to the header of an outbound message: Expect: 102- processing. This is an HTTP response code that indicates processing is in progress. If the receiving server supports 102 responses, the header triggers the server to send 102 responses to the client repeatedly until the server has completely processed the inbound message. Before selecting this option, make sure the server supports 102 responses. If you turn on 102 processing and the server does not support it, the server will return a 417 message (the server could not meet the expectation given in the Expect header) and the connection may fail. If the receiving partner uses the embedded HTTP server in Interchange or Activator 5.5.1 or later, 102 responses are supported. This also is supported if your partner uses Jetty 6 or later.
Back up the files that go through this transport
Select this option if you want the system to back up copies of the messages it receives from partners. Backing up files is strongly recommended. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server stops or restarts. Backups also are needed if you want the ability to resubmit messages to back-end applications or resend messages to partners. Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Post-processing script
The full path to an executable file that contains post-processing commands.